1. Technical Field
The technical field relates to multimedia broadcasting and/or multicasting in a wireless communications context.
2. Related Art and Other Considerations
There is an ever increasing demand for wireless communication devices to perform a variety of applications. Current and future generations of mobile wireless communications devices, referred generally and generically hereafter as user equipment units (UEs), are striving to deliver multimedia services using one or both multicasting or broadcasting modes. Multicasting directs streaming media (audio, video, etc.) to plural specific subscribers. In contrast, broadcasting provides content that can be accessed by anyone with suitable equipment. Television and radio are examples of broadcasting, and a pay-per-view webcast is an example of multicasting.
A new service, called multimedia broadcast multicast service (MBMS), is being developed for both these modes of operation. MBMS will provide point-to-multi-point transmissions of multimedia data like text, audio, and video from a single point source over a radio interface to a broadcast area or to a multicast group. Although the content will typically be in a streaming format, e.g., MPEG/H.261 visual data and associated audio data, any content or format may be used. Similarly, the media can be delivered streamed, on-demand, or at a scheduled time. MBMS is described, e.g., in 3GPP TS 25.246 v6.3.0 (2004-06), 3rd Generation Partnership Project: Technical Specification Group Services and Systems Aspects; Multimedia Broadcast/Multicast Service (MBMS); Architecture and functional description (Release 6).
The MBMS session content is provided as a data stream from the content provider to a gateway GPRS support node (GGSN) in the packet data core network. The GGSN delivers the data stream to each serving GPRS support node (SGSN) that has one or more user equipment unit MBMS subscribers having an “activated MBMS context” in the SGSN's geographic coverage area. A base station controller (BSC) may well supervise the cell areas in which user equipment units (UEs) from multiple SGSNs in the MBMS session pool are located.
FIG. 1 illustrates an example system that supports wireless communications and MBMS services. This system may accommodate one or more standard architectures including a universal mobile telecommunications system (UMTS) (as well as other systems) based on code division multiple access (CDMA), GPRS/EDGE and other systems based on time division multiple access (TDMA), etc.
As shown in FIG. 1, one or more example radio access networks (RAN) provide radio access services to/from a user equipment unit (UE) 20 over a wireless interface (e.g., Uu or Um). Interfaces are represented in FIG. 1 by dot-dashed lines. The user equipment unit (UE) 20, also termed a mobile terminal, can be any mobile station such as a mobile telephone (“cellular” telephone) and laptops with mobile termination, and thus can be, for example, portable, pocket, hand-held, computer-included, or a car-mounted mobile device which communicates voice and/or data with the radio access network.
The example radio access networks can include one or more of a UMTS terrestrial radio access network (UTRAN) 24 and a GPRS/EDGE radio access network (GERAN) 25, both of which are used in third generation cellular systems. The RAN may also be a generic access network (GAN) and the RAN node a generic access network controller (GANC). Transport of information over the communications interface between the RBS/Node B and RNC/BSC/GANC interfaces is typically based on asynchronous transfer mode (ATM) or Internet Protocol (IP).
A RAN includes one or more radio network controllers (RNCs), base station controllers (BSCs), or generic access network controllers (GANCs). Each controller is coupled to one or more radio base stations (BSs), sometimes referred to as Node B's. For example, the UTRAN 24 illustrated in FIG. 1 has included one or more radio network controllers (RNCs) 26 and one or more base stations (BS) 28. For sake of simplicity, the UTRAN 24 of FIG. 1 is shown with only two RNC nodes, particularly RNC 261 and RNC262. Each RNC 26 is connected to one or more base stations (BS) 28. For example, and again for sake of simplicity, two base station nodes are shown connected to each RNC 26. In this regard, RNC 261 serves base station 281-1 and base station 281-2, while RNC 262 serves base station 282-1 and base station 282-2. Each base station can serve one or more cells. It will be appreciated that a different number of base stations can be served by each RNC, and that RNCs need not serve the same number of base stations.
FIG. 1 shows that an RNC can be connected over an Iur interface to one or more other RNCs in the UTRAN 24. In order to support continuation of established connections when the UE is moving between cells controlled by different RNCs in the Radio Access Network, a Signalling Network (e.g. Signalling System No 7) enables RNCs to perform the required RNC-RNC signaling.
Those skilled in the art appreciate that, with respect to a certain RAN-UE connection, an RNC can either have the role of a serving RNC (SRNC) or the role of a drift RNC (DRNC). If an RNC is a serving RNC (SRNC), the RNC is in charge of the connection with the user equipment unit (UE), e.g., it has full control of the connection within the radio access network (RAN). A serving RNC (SRNC) is connected to the core network. On the other hand, if an RNC is a drift RNC (DRNC), its supports the serving RNC (SRNC) by supplying radio resources (within the cells controlled by the drift RNC (DRNC)) needed for a connection with the user equipment unit (UE). A system which includes the drift radio network controller (DRNC) and the base stations controlled over the Iub Interface by the drift radio network controller (DRNC) is herein referenced as a DRNC subsystem or DRNS. An RNC is said to be the Controlling RNC (CRNC) for the base stations connected to it by an Iub interface. This CRNC role is not UE specific. The CRNC is, among other things, responsible for handling radio resource management for the cells in the base stations connected to it by the Iub interface.
The UTRAN 24 communicates with core network serving GPRS support nodes (SGSNs) 30 over an Iu interface. The GERAN 25 communicates with core network serving GPRS support nodes (SGSNs) 30 over a Gb (or optionally Iu) interface.
SGSN 30 supports packet-based communications and provides functions such as authentication, ciphering, mobility management, charging data, and logical link management toward the user equipment unit 20. SGSN 30 is coupled to a UE subscriber database called the home location register (HLR) 32 over a Gr interface.
A gateway GPRS support node (GGSN) 34 communicates with one or more SGSNs over a Gn/Gp interface. Gateway GRPS support node (GGSN) 34 provides the interface towards the packet-switched networks (e.g., the Internet, X.25 external networks) and translates data formats, signaling protocols, and address information in order to permit communication between the different networks.
The gateway GPRS support node (GGSN) 34 communicates with a broadcast multicast service center (BM-SC) 36 over a Gmb/Gi interface. The multicast/broadcast content is provided by a MBMS content provider 38.
The broadcast multicast service center (BM-SC) 36 provides functions for MBMS user service provisioning and delivery such as serving as an entry point for content provider MBMS transmissions and authorizing and initiating MBMS Bearer Services within the PLMN. The BM-SC 36 is a functional entity that exists for each MBMS User Service. The BM-SC 36 generates charging records for content provider transmitted data, and provides the GGSN 34 with transport associated parameters such as quality-of-service and one or more MBMS service areas. Further, the BM-SC 36 may schedule MBMS session transmissions and retransmissions, retrieve content from external sources and provide this content using MBMS bearer services. The BM-SC 36 labels each MBMS session with an MBMS Session Identifier to allow the UE 20 to distinguish the MBMS session retransmissions. Each transmission and subsequent retransmission of a specific MBMS session are identified by a common MBMS Session Identifier (e.g., 2-3 octets) passed at the application layer in the content, which may also be passed in a shortened form (i.e., the least significant octet) in a MBMS Session Start Request message to sent to the RNCs/BSCs/GANCs in the RANs.
The GGSN 34 serves as an entry point for IP multicast traffic as MBMS data. Upon notification from the BM-SC 36, the GGSN 34 requests establishment of a bearer plane for a broadcast or multicast MBMS transmission. Bearer plane establishment for multicast services is carried out towards each SGSN (usually there are multiple such SGSNs) that have requested to receive transmissions for the specific multicast MBMS bearer service. The GGSN 34 receives IP multicast traffic (whether from BM-SC 36 or other data sources) and routes the traffic to the proper GTP tunnels set-up as part of the MBMS bearer service.
The SGSN role within MBMS architecture is, e.g., to perform MBMS bearer service control functions for each individual UE and to provide MBMS transmissions to UTRAN/GERAN/GAN. The SGSN 30 supports intra-SGSN and inter-SGSN mobility procedures, which requires the SGSN 30 to store a user-specific MBMS UE context for each activated multicast MBMS bearer service and to pass these user-specific MBMS UE contexts to the new SGSN during inter-SGSN mobility procedures. The SGSN 30 must generate charging data per multicast MBMS bearer service for each user. Each SGSN 30 initially tries to establish Iu/Gb and Gn bearers shared by many users on demand when data has to be transferred to the users. But as described below, the Iu and Gb bearer establishment is controlled by the RNC/BSC/or GANC.
FIG. 2 illustrates phases of an MBMS multicast service. There are eight phases: subscription, service announcement, joining, session start, MBMS notification, data transfer, session stop, and leaving. The subscription, joining, and leaving phases are performed individually per user. The other phases are performed for all users interested in the related service.
The subscription phase establishes the relationship between the user and the service provider, which allows the user to receive the related MBMS multicast service. A subscription is an agreement of a user to receive service(s) offered by an operator. Subscription information is recorded in the BM-SC. MBMS user service announcement/discovery mechanisms allow users to request or be informed about the range of MBMS user services available.
A service announcement distributes to users information about the service, parameters required for service activation (e.g. IP multicast address), and possibly other service-related parameters (e.g. service start time).
Joining (i.e., MBMS multicast activation by the user) is the process by which a subscriber joins (becomes a member of) a multicast group, i.e., the user indicates to the network that he/she is willing to receive multicast mode data of a specific MBMS bearer service.
Session start is the point at which the BM-SC is ready to send data and occurs independently of activation of the service by the user. Session start also triggers bearer resource establishment for MBMS data transfer.
MBMS notification informs the UEs about forthcoming (and potentially about ongoing) MBMS multicast data transfer, and data transfer is the phase when MBMS data are transferred to the UEs.
Session stop is the point at which the BM-SC determines that there will be no more data to send for some period of time. This period is preferably long enough to justify removal of bearer resources associated with the session. At the leaving phase, a subscriber leaves (stops being a member of) a multicast group.
FIG. 3 illustrates phases of an MBMS broadcast service. There are five phases: service announcement, session start, MBMS notification, data transfer, and session stop. These phases have already been described above.
Radio Resource Control (RRC) is a layer 3 signalling protocol used between the radio access network and the user equipment unit (UE) 20, to support the management of radio resources. A user equipment unit (UE) 20 in the RRC protocol operates in a state model conceptualized as having two modes: an Idle Mode and a Connection Mode. The Idle Mode is entered after power on. In Idle Mode there is no connection between the user equipment unit (UE) and the UTRAN. When a connection is established, the user equipment unit (UE) is assigned a U-RNTI and the mobile terminal enters Connected Mode. The U-RNTI (UTRAN Radio Network Temporary Identity) is a global identity, which can be used in any cell in the UTRAN.
A URA (UTRAN Routing Area) is a geographical area comprising of one or more cells. Each URA is identified by a unique identity, which is broadcast in all cells belonging to the URA. A URA can comprise cells controlled by more than one RNC
Within Connected Mode there are four different states: CELL_DCH state; CELL_FACH state; CELL_PCH state; and URA_PCH. Each state reflects a different level of activity. The CELL_DCH state is characterized, e.g., by having a dedicated channel (DCH) assigned to the user equipment unit (UE). In the CELL_FACH state, no dedicated physical channel is assigned, but the user equipment unit (UE) listens continuously to a common channel (the FACH) in the downlink belonging to the selected cell. In the uplink, the user equipment unit (UE) typically uses a random access channel (RACH). In the CELL_PCH state, the user equipment unit (UE) monitors a paging channel (PCH) of a selected cell. The URA_PCH state is almost identical to the CELL_PCH state. The difference is that the user equipment unit (UE) does only update the network of its location after crossing URA borders. An URA (UTRAN. Registration Area) is a group of cells. This means that in this state the position of the user equipment unit (UE) is in general known only on URA level.
Each RNC 26 which is controlling one or several cells within an MBMS Service area maintains a CRNC MBMS Service Context (“MBMS Service Context”) for each MSM Service. The MBMS Service Context contains a list of PMM connected mode user equipment units (UEs) which are present in one or several cells of the RNC and which have activated the MBMS service, and/or a list of UTRAN Routing Areas (URAs) in which there is at least one URA_PCH user equipment unit (UE) which has activated the MBMS service. The list includes at least the U-RNTI of the user equipment units (UEs) in a state other than URA-PCH and/or URA identifiers (URA-IDs).
In standards there are basically three methods described where MBMS Service Context is built up in RAN (see, e.g., 3GPP TS 25.346 v6.3.0 (2004-12), 3rd Generation Partnership Project: Technical Specification Group Radio Access Network; Introduction of the Multimedia Broadcast Multicast Service (MBMS) in the Radio Access Network (RAN); Stage 2 (Release 6)). These three methods refer to “RNC registration”. RNC Registration for a certain MBMS service denotes the process wherein the core network, e.g., SGSN 30, becomes aware of an RNC hosting user equipment units (UEs), which have activated that MBMS service.
A first method for acquiring a MBMS Service Context involves implicit registration of a RNC node to the core network. This is the implicit (no additional signaling required over Iu) method where a RNC in it is role of SRNC is registered in a SGSN whenever a mobile moves (from RRC Idle/URA_PCH/CELL_PCH) to CELL_FACH/CELL_DCH to set up a PS RAB at MBMS join or in CELL_FACH/CELL_DCH is joining a MBMS Service.
A second method for acquiring a MBMS Service Context involves explicit registration of a RNC node to the core network. This is the explicit method where a RNC in it is role of DRNC signals to its default SGSN to be registered for the first joined UE for which it is a DRNC.
A third method for acquiring a MBMS Service Context involves registration based on Routing Areas (RA). This is an implicit method where the RAs are registered for mobiles which have joined the MBMS service. The RAU procedure implicitly gives the RA for joined mobiles.
The registration information is used by the core network to distribute a MBMS Session Start Request message to RNCs where there are joined user equipment units (UEs) and to set up Iu user plane resources for the MBMS session.
Another important issue is that the MBMS Session Start Request message paging over UTRAN, the implication of this is that paging load.
So far the stage 2 specification (3GPP TS 25.346) specifies that the UE is linked to a MBMS Service Context in the SRNC when the mobile is joining the service and is in PMM-CONNECTED, or in case the mobile sets up a packet switch radio access bearer (PS RAB). This may happen at any point in time, before and during sessions. The consequences of this are that a MBMS UE context will be established in the SRNC via the UE linking procedure over Iu, whenever the mobile is joining the service.
According to 3GPP TS 25.346 v6.3.0, a MBMS Service Context for a session is made available to RAN via individual UE linking over Iu before session start. The SRNC uses the context information for tracking purposes, point-to-point (ptp) bearer set up and for paging considerations. The SRNC is also responsible for Iur-linking.
3GPP TS 25.346 v6.3.0 does not specifically state when the Iur-linking procedure occurs, i.e., when the DRNC is informed of the MBMS UE context from SRNC. The main purpose of Iur-linking is to provide the DRNC (in its role of the CRNC) with information for making a ptp/ptm (point-to-point/point-to-multipoint) decision on a cell by cell basis, and for channel configuration for the MBMS transmission in case of a point-to-multipoint (ptm) decision. There are two main possibilities: Early Iur-linking and late Iur-linking, i.e. Iur-linking only at MBMS session start.
3GPP TS 25.346 v6.3.0 allows linking over Iur to be performed at service activation, at session start, and during an ongoing session (a user equipment joins an ongoing session). The early Iur-linking and late Iur-linking are indeed one and the same procedure. They differ only in the circumstances when they are respectively triggered. The early Iur-linking is a complementary procedure, such that late Iur-linking is a mandated procedure and must be implemented in SRNC to support late arrivals of user equipment units (UEs) when a session has started. The early Iur-linking is an optional feature and provides optimization of signalling load processing at MBMS session start.
What is needed, therefore, and an object herein provided for, are means, methods, and techniques for providing or controlling registration of a drift radio network control node at a core network in conjunction with a Iur Linking Procedure for a MBMS service.